Using loadPagesSequentially Flash Variable

Prizm Content Connect v6 and higher includes the following:

A flash variable (loadPagesSequentially) that changes several aspects of the client’s paging behavior.
Sample code that more efficiently handles requests.

For best results, set "loadPagesSequentially" to "No", and use the page conversion algorithm (PCC\Convert.ashx in the C# sample) in your server.

If you omit loadPagesSequentially, the client will use its default value of "Yes" and behave like previous versions of the client. If you set the variable to "No", the client will change behavior in several useful ways:

First, as soon as it knows that the document has more than one page, the client will visibly reserve space for pages that it has not yet loaded. The most obvious effect is that the document scrollbar will allow an end user to scroll to any page in the document, even if that page is not yet loaded. When displaying pages that are not yet loaded, the client will fill its space with the gray background.
Second, the client will always try to download pages that are visible, even if it has to request pages out of order.
Finally, when "loadPagesSequentially" is set to "No", the viewer will initialize itself differently in order to get better performance.

It is important to consider that the second and third behavior changes above will actually result in slower performance unless the web tier is changed as well. To help with that effort, the C# sample has been updated to accommodate these changes.

The sample operates more efficiently by avoiding individual requests, and instead relying more on the pages generated by "enterprise=3" in the Default.aspx page. This is comprised of two parts: the sample can guess when a page will be cached soon, and it can choose to wait for that cached page rather than requesting the page separately.

The sample predicts that a page will be cached by looking for the presence of a nearby page in the cache. For example, if the client has requested page 42, while page 41 is cached and 42 is not, then the sample predicts that page 42 will be cached very soon and it is actually faster to wait for it than to request it separately. This is true because there is a noticeable cost to reopening a document, especially for large word-processing documents.

The sample waits for pages to be cached by looping for a predetermined amount of time (with a sleep in the middle of the loop to avoid wasting CPU time). If the page is generated and placed into the cache during this time, it will be returned immediately. Otherwise the sample will request it separately.